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FOREWORD 


i 

i 

I  The  complexity,  cost,  and  military  value  of  defense  Command  and  Control  (C2)  systems  continue  to 

;  increase.  Therefore,  it  is  important  that  we  acquire  these  systems  efficiently  and  effectively.  Two  major 

i  studies  of  past  acquisitions  of  C2  systems  conclude  that  use  of  conventional  strategies  for  ac- 

[  quiring  such  systems  often  leads  to  unsatisfactory  results.  The  findings  of  both  studies  stress 

;  the  point  that  consideration  be  given  to  acquiring  C2  systems  in  an  evolutionary  way. 

In  consonance  with  these  findings,  current  Office  of  the  Secretary  of  Defense  (OSD)  guidance 
1  supports  the  use  of  an  Evolutionary  Acquisition  (EA)  strategy  in  acquiring  systems  of  this  kind, 

while  at  the  same  time  noting  that  the  unique  circumstances  of  individual  programs  should  be 
considered  and  that  the  strategy  chosen  must  remain  consistent  with  basic  DOD  acquisition 
policy. 

The  Joint  Logistics  Commanders  endorse  this  OSD  guidance.  We  are  publishing  this  guide 
to  encourage  consideration  and  use  of  an  EA  strategy  by  the  services  in  acquiring  C2  systems. 
While  this  guidance  is  aimed  specifically  at  the  use  of  an  EA  strategy  in  acquiring  Command 
and  Control  systems,  the  principles  discussed  may  also  be  applicable  to  the  acquisition  of  other 
kinds  of  systems.  This  EA  strategy  is  of  a  character  that  the  system  is  not  required  to  have 
full  capability  when  deployed,  but  will  evolve  to  full  capability  through  one  or  more  incremental 
upgrades.  Considered  most  broadly,  EA  consists  of  first  defining  the  general  outline  of  an  overall 
system;  and  then  sequentially  defining,  funding,  developing,  testing,  fielding,  supporting  and 
evaluating  increments  of  the  system. 

This  guide  was  prepared  under  the  direction  of  the  Commandant,  Defense  Systems  Manage¬ 
ment  College  (DSMC),  who  also  has  accepted  the  responsibility  for  keeping  this  document 
current. 
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PREFACE 


Responding  to  a  request  of  the  Joint  Logistics  Commanders  (JLC)  that  DSMC  prepare  policy  guidelines 

for  the  use  of  an  EA  approach  when  acquiring  C2  systems,  the  Commandant,  DSMC,  established  a 

project  team  comprising  the  undersigned  persons.  The  findings  of  this  project  team  are: 

•  Significant  studies  have  been  conducted  in  the  field  of  EA  by  authoritative,  learned  and  experi¬ 
enced  groups  representative  of  public  and  private  sectors  of  our  economy.  These  studies  have 
concluded  that  for  the  acquisition  of  C2  systems  an  EA  approach  should  normally  be  used. 
While  these  studies  have  not  been  approved  by  the  Secretary  of  Defense  and  the  military  services, 
the  findings  are  judged  to  be  such  that  an  EA  approach  should  be  at  least  considered  for  appli¬ 
cation  when  warranted  by  the  nature  of  the  program. 

•  OSD  senior  executives  have  been  of  the  view  that,  while  OSD  should  not  attempt  to  dictate  to  the 
services  when  they  should  use  EA,  OSD  policy  documents  do  delineate  EA  as  an  acceptable  ac¬ 
quisition  strategy  for  C2  systems. 

•  Documentation  defining  OSD-level  guidance  concerning  the  use  of  EA,  while  available,  is  largely 
unknown  by  members  of  the  acquisition  community. 

•  The  DSMC  project  team,  as  a  result  of  its  own  deliberations,  supports  the  use  of  EA  as  an  alter¬ 
native  strategy  for  acquisition  of  C2  systems. 

•  A  JLC-endorsed  guide  for  the  use  of  evolutionary  acquisition  would  be  of  value  in:  1)  expressing 
JLC  support,  2)  bringing  together  OSD-level  guidance,  3)  providing  perspective  on  when  and  why 
to  use  EA,  4)  explaining  what  EA  is,  and  5)  identifying  management  and  technical  issues  requiring 
special  attention  in  successfully  implementing  an  EA  strategy. 

This  guide  has  been  prepared  with  these  five  findings  in  mind. 

We  hope  that  the  guide  will  prove  to  be  of  benefit  to  the  acquisition  community  in  general,  and  to  pro¬ 
gram  managers  in  particular,  in  appropriately  and  productively  applying  the  EA  approach  in  ac¬ 
quiring  C2  systems. 

Comments  on  this  document  are  invited  and  may  be  addressed  to  the  Commandant,  DSMC;  Attn:  DRI; 
Fort  Belvoir,  VA  22060-5426. 


EDWARD  HIRSCH 

FRANCIS  W.  A'HEARN 

DR.  C.  E.  BERGMAN 

BG,  USA  (Ret) 

COL,  USAF 

Air  Force  Chair 

Director,  Center 

Executive  Institute 

for  Acquisition 

DSMC 

Management  Policy 
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SECTION  1 

POLICY 


Existing  Office  of  Management  and  Budget  (OMB) 
and  Office  of  the  Secretary  of  Defense  (OSD) 
policy  encourages  the  application  of  the  EA  ap¬ 
proach  to  the  acquisition  of  C2  systems.  OMB 
Circular  A-109  and  DOD  Directive  5000.1  both  ex¬ 
plicitly  call  for  tailoring  an  acquisition  strategy  to 
meet  the  specific  needs  and  circumstances  per¬ 
taining  to  an  individual  acquisition  program.  In 
support  of  this  general  guidance,  DOD  Instruction 
5000.2  calls  for  consideration  of  “Evolutionary 
Development  and  Acquisition  of  Command  and 
Control  Systems.’’  Providing  more  specific 
guidance,  Defense  Acquisition  Circular  76-43 
states  that  “C2  systems  generally  require  an 
evolutionary  acquisition  approach.’’1 

The  Joint  Logistics  Commanders  endorse  this 
guidance  from  OMB  and  OSD.  Acquisition 
managers  should  become  familiar  with  the  con¬ 
tents  of  this  guide,  and  should  give  deliberate  and 
careful  consideration  to  the  possible  use  of  an 
Evolutionary  Acquisition  (EA)  strategy  in  the  ac¬ 
quisition  of  Command  and  Control  (C2)  systems. 

When  evolutionary  acquisition  is  used  for  a  par¬ 
ticular  program,  it  is  imperative  that  all  personnel 
concerned  with  the  program  give  their  full  support 
and  cooperation  in  the  formulation  and  execution 


of  the  strategy— especially  in  those  areas  involv¬ 
ing  departure  from  customary  practices. 

An  evolutionary  acquisition  program  may  involve 
a  number  of  individuals  and  organizations  outside 
of  those  organizations  reporting  to  the  Joint 
Logistics  Commanders,  and  the  support  of  these 
other  persons  and  groups  can  be  crucial  to  the 
success  of  the  program.  The  Joint  Logistics  Com¬ 
manders  urge  that  such  other  persons  and  groups 
become  familiar  with  the  principles,  potential 
benefits  and  potential  pitfalls  of  EA,  as  outlined 
in  this  Guide. 

Establishing  effective  patterns  of  interaction  with 
external  organizations  involved  in  an  evolutionary 
acquisition  can  be  expected  to  be  unusually  dif¬ 
ficult,  because  the  very  nature  of  EA  requires  rela¬ 
tionships  and  interactions  different  from  the  norm. 
The  Joint  Logistics  Commanders  will,  if  necessary, 
assist  subordinate  commanders  and  their  program 
managers  in  their  efforts  to  negotiate  effective  pat¬ 
terns  of  interaction  with  external  organizations. 

Finally,  use  of  an  appropriate  acquisition 
strategy— EA  or  any  other— will  not  by  itself  lead 
to  a  successful  program.  Excellent  management 
and  strong  support  by  all  involved  are  vital  also. 


’The  OMB  AND  OSD  Policy  guidelines  are  given  in  some  detail  in  Section  6.  The  EA  process  is  sum¬ 
marized  in  Section  2  and  described  in  detail  in  Section  4 
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SECTION  2 


AN  OVERVIEW  OF  EVOLUTIONARY  ACQUISITION 


Two  major  studies1  of  past  acquisitions  of  Com¬ 
mand  and  Control  (C2)  systems  have  found  that 
the  use  of  conventional  approaches  to  acquisition 
of  such  systems  often  has  led  to  unsatisfactory 
results.  The  systems  considered  in  these  studies 
were  large,  software-dominated  information 
systems  intended  to  aid  operational  commanders 
in  performing  their  command  and  control 
functions. 

Difficulties  have  arisen  primarily  because  for  com¬ 
mand  and  control  systems  it  is  often  not  feasible 
to  define  in  detail — before  starting  full-scale 
development— what  the  operational  capabilities 
and  the  functional  characteristics  of  the  entire 
system  are  to  be.  If  full-scale  development — on  a 
total-system  basis — of  any  system  is  undertaken 
without  a  clear  definition  of  the  operational  con¬ 
cepts  and  capabilities  and  the  functional 
characteristics  the  entire  system  is  to  have,  then 
it  is  very  likely  that  the  development  process  will 
be  long,  costly,  and  unstable,  and  that  the  system 
developed  will  be  unsatisfactory. 

In  consideration  of  these  difficulties,  the  two 
studies  referred  to  above  recommend  the  use  of 
an  evolutionary  acquisition  strategy  in  acquiring 
C2  systems. 

Evolutionary  Acquisition  is  defined  as  follows: 

Definition  of  Evolutionary  Acquisition 

Evolutionary  acquisition  is  an  acquisition  strategy 
which  may  be  used  to  procure  a  system  expected 
to  evolve  during  development  within  an  approved 
architectural  framework  to  achieve  an  overall 
system  capability.  An  underlying  factor  in  evolu¬ 
tionary  acquisition  is  the  need  to  field  a  well- 
defined  core  capability  quickly  in  response  to  a 
validated  requirement,  while  planning  through  an 
incremental  upgrade  program  to  eventually 
enhance  the  system  to  provide  the  overall  system 
capability.  These  increments  are  treated  as  in¬ 
dividual  acquisitions,  with  their  scope  and  content 


being  the  result  of  both  continuous  feedback  from 
developing  and  independent  testing  agencies  and 
the  user  (operating  forces),  supporting  organiza¬ 
tions,  and  the  desired  application  of  new 
technology  balanced  against  the  constraints  of 
time,  requirements,  and  cost. 

Evolutionary  acquisition,  as  defined  above,  com¬ 
prises  the  following  elements: 

•  A  concise  statement  of  operational  concepts 
and  requirements  for  the  full  system. 

•  A  general  description  of  the  functional 
capability  desired  for  the  full  system.  (The  lack 
of  specificity  and  detail  in  identifying  the  final 
system  capability  distinguishes  EA  from  an 
acquisition  strategy  that  is  based  on  P3I.) 

•  A  flexible,  well-planned  overall  architecture, 
to  include  process  for  change,  which  will  allow 
the  system  to  be  designed  and  implemented 
in  an  incremental  way. 

•  A  plan  for  incremental  achievement  of  the 
desired  total  capability. 

•  Early  definition,  funding,  development, 
testing,  fielding,  supporting  and  operational 
evaluation  of  an  initial  increment  of  opera¬ 
tional  capability. 

•  Sequential  definition,  funding,  development, 
testing,  fielding,  supporting  and  operational 
evaluation  of  additional  increments  of  opera¬ 
tional  capability. 

•  Continual  dialog  and  feedback  among  users, 
developers,  supporters  and  testers. 

Some  important  EA  attributes  which  can  help  im¬ 
prove  the  probability  of  fielding  successful  C2 
systems  are: 

•  Separate  funding  approval  for  each  increment 
of  operational  capability,  which  should 
facilitate  control  of  program  costs. 


’“Report  of  the  Defense  Science  Board  Task  Force  on  Command  and  Control  Systems  Management,” 
July  1978,  Office  of  the  Under  Secretary  of  Defense  Research  and  Engineering,  Washington,  DC. 
"Command  and  Control  (C2)  Systems  Acquisition  Study  Final  Report."  September  1,  1982  The  Armed 
Forces  Communications  and  Electronic  Association,  Falls  Church,  Va. 


•  Careful  planning  so  that  development, 
operational  testing,  deployment,  and  support 
of  the  baseline  system  and  incremental  up¬ 
grades  can  proceed  rapidly. 

•  Use  of  the  “Build  a  little,  Test  a  little,  Field  a 
little”  development  philosophy,  which  should 
result  in  timely  fielding  and  support  of  each 
increment  of  operational  capability. 

•  Continuous  user  involvement  and  feedback, 
which  should  enhance  user  satisfaction. 

•  Use  of  flexible  system  architecture,  which 
should  facilitate  evolutionary  enhancement 
and  expansion  of  the  system  while  the  mis¬ 
sion  continues  to  be  supported. 


Successful  execution  of  an  evolutionary  acquisi¬ 
tion  program  requires  a  number  of  changes  to  rela¬ 
tionships  and  practices  common  to  more  conven¬ 
tional  acquisition  programs.  One  difficult  yet  im¬ 
portant  area  of  change  is  the  need  for  a  much 
closer,  interactive  set  of  relationships  among  the 
real  user  (the  Commander  and  staff  who  will  use 
the  system),  the  surrogate  user  (representative  of 
the  real  user),  the  independent  tester,  the 
developer,  and  the  supporter.  Another  difficult,  im¬ 
portant  area  is  the  need  for  streamlined  pro¬ 
cedures  to  allow  each  increment  of  capability  to 
progress  rapidly  through  definition,  funding, 
development,  testing,  fielding,  operational  evalua¬ 
tion  and  integration  into  the  support  environment. 


SECTION  3 


C2  SYSTEMS:  THEIR  CHARACTERISTICS,  AND  WHY  THEY 
MAY  REQUIRE  AN  ALTERNATIVE  ACQUISITION  STRATEGY 


Command  and  Control  systems  have  a  number 
of  characteristics  which  differentiate  them  from 
other  systems.  These  systems: 

•  Are  primarily  information  systems,  aimed  at 
assisting  operational  commanders  in  han¬ 
dling  information  concerning  hostile  and 
friendly  forces,  in  deciding  upon  courses  of 
action,  and  in  monitoring  execution  of  opera¬ 
tional  orders. 

•  Are  computer-software  dominant. 

•  May  be  tightly  coupled  with  particular  opera¬ 
tional  settings  and,  thus,  may  be  aligned  with 
specific  geographical  parameters,  specific 
ranges  of  threats,  and  specific  doctrines. 

•  May  be  “one-of-a-kind.” 

•  May  be  in  support  of  a  unified  or  specified 
command:  may  connect  with  higher,  lower 
and  collateral  commands;  and  may  be  re¬ 
quired  to  be  interoperable  with  multi-service 
or  multi-national  C2  systems. 

•  May  be  required  to  meet  the  specific  needs 
and  desires  of  specific  individual  operational 
commanders. 

•  Must  be  highly  adaptable  to  meet  the  many 
demands  a  commander  may  place  upon  them 
in  the  myriad  of  circumstances  that  can  arise 
in  battle. 

•  Must  perform  acceptably  with  imperfect  infor¬ 
mation,  and  their  performance  should 
degrade  gradually,  rather  than  fail 
catastrophically,  under  damage  and  stress. 

•  Must  have  a  highly  responsive  logistical  sup¬ 
port  system  to  sustain  high  readiness  and 
operational  performance  capabilities. 

Stemming  from  the  above  are  several  additional 
characteristics,  which  are  highly  significant  from 
an  acquisition  standpoint: 

•  Due  to  the  complex  interactions  between  the 
commander  and  his  staff  on  the  one  hand, 
and  the  software  and  hardware  of  his  C2 
system  on  the  other,  it  may  not  be  feasible 
to  define  the  desired  software  and  hardware 


characteristics  by  other  than  an  iterative, 
trial  and  error  process  involving  the  actual 
user  and  portions  of  the  system.  It  is,  of 
course,  necessary  to  define  the  architecture 
within  which  the  software  and  hardware 
characteristics  must  evolve,  the  required 
broad  capabilities  of  the  fully  evolved  system, 
and  the  approximate  date  by  which  the  full 
capability  is  required.  (In  considering  com¬ 
mand  and  control,  it  should  be  noted  that 
command  and  control  are  the  paramount 
functions  of  an  operational  commander,  and 
that  he  and  his  staff  are  integral  with  and  are 
the  most  important  parts  of  his  overall  com¬ 
mand  and  control  capability.) 

•  Due  to  the  fact  that  C2  systems  often  must 
operate  interactively  with  other  such  systems, 
defining  external  system  interfaces  and  oper¬ 
ational  concepts  are  inherently  difficult  and 
sometimes  may  be  done  best  on  an  iterative 
basis.  Due  to  the  impact  this  may  have  on 
development  of  other  systems,  this  approach 
should  be  laid  out  carefully  in  Decision 
Coordination  Papers  and  other  program 
documentation.  An  iterative  approach  also 
may  be  best  suited  to  defining  certain  inter¬ 
nal  system  interfaces;  for  example,  in 
developing  protocols  for  handling  multiple 
levels  of  security  within  a  particular  system. 
(As  this  example  suggests,  sometimes  it 
might  be  difficult  to  define  whether  a  par¬ 
ticular  functional  capability  is  part  of  one 
system  versus  another,  or  whether  it  might 
be  considered  simultaneously  to  be  part  of 
two  [or  more)  systems.) 

For  a  system  having  the  above  characteristics,  it 
most  likely  would  not  be  feasible  to  define  in 
detail— before  starting  full-scale  development— 
what  the  operational  capabilities  and  the  functional 
characteristics  of  the  entire  system  are  to  be. 

However,  if  full-scale  development  for  the  total 
system— of  any  system  is  undertaken  without  a 
clear  deflation  of  the  users  operational  concepts 
and  capabilities  and  the  functional  characteristics 
of  the  entire  system,  then  it  is  very  likely  that  the 


development  process  will  be  long,  costly  and 
unstable,  and  that  the  system  developed  will  be 
unsatisfactory. 

Thus,  for  C2  systems,  as  characterized  above,  a 
conventional  acquisition  strategy  is  unlikely  to  lead 
to  satisfactory  results.  A  conventional  acquisition 
strategy  requires  a  detailed  definition  of  the 
capabilities  and  characteristics  of  the  entire  system 


before  starting  full-scale  development,  and  for  the 
systems  being  discussed  here,  this  is  not  possi¬ 
ble.  Therefore,  using  a  conventional  acquisition 
strategy  to  develop  such  a  system  could  lead  to 
many  of  the  problems  discussed  above. 

Evolutionary  acquisition,  an  alternative  approach 
to  the  acquisition  of  C2  systems,  is  described  in 
the  next  section. 
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EVOLUTIONARY  ACQUISITION:  WHAT  IT  IS,  WHAT  IT  IS  NOT 


General  Description 

Evolutionary  acquisition  is  an  acquisition  approach 
especially  well  suited  for  large  C2  system  acquisi¬ 
tion.  It  is  both  adaptive  and  incremental.  It  requires 
a  users  concept  of  operations  and  a  description 
of  the  overall  system  capability  desired,  issued  by 
an  accountable  authority.  This  documentation 
defines  the  architectural  framework  within  which 
evolution  is  to  occur,  defines  the  core  or  baseline 
capability  necessary,  and  describes  the  final 
desired  capability.  This  does  not  necessarily  im¬ 
ply  the  need  to  develop  the  detailed  system 
description  prevalent  in  conventional  systems  ac¬ 
quisition  documentation. 

An  initial  core  element  is  a  well-defined,  essen¬ 
tial  entity  that: 

•  Will  significantly  enhance  the  users  mission 
capability. 

•  Can  be  fielded  quickly  and  sustained  in  its 
operational  environment. 

Combined  user-developer-supporter  effort,  the  key 
ingredient  to  assist  the  requirement-setter  in  op¬ 
timum  definition  of  the  core  element,  is  a  principal 
characteristic  of  the  EA  approach.  It: 

•  Continues  throughout  the  system  life  cycle  in 
order  to  develop  recommendations  for  system 
operational  and  support  requirements  for 
each  incremental  upgrade. 

•  Provides  the  essential  feedback  from  user  to 
requirement-setter,  developer,  and  supporter 
that  is  an  integral  part  of  the  evolutionary 
process. 

During  core  element  testing,  and  even  after  por¬ 
tions  of  the  system  are  fielded,  the  user  continues 
to  support  an  ongoing  system  evaluation  by  pro¬ 
viding  inputs  from  his  unique  perspective. 

Incremental  system  development  and  sustaining 
support  beyond  the  core  element  is  governed  by 
an  evolutionary  plan.  The  plan  requires  flexibility 
to  accommodate  periodic  performance  update 
through  incremental  upgrades  defined  based  upon 
input  from  the  developer-user-tester-supporter 
team  as  they  test  and  assess  system  operational 
use.  The  plan  is  essentially  a  baseline  from  which 


adjustments  are  made  as  dictated  by  the  results 
of  continuing  feedback  from  tests  and 
assessments  of  operational  use. 

In  summary,  system  operational  capabilities  are: 

•  Established  by  the  requirement-setter  in  coor¬ 
dination  with  the  developer-user-supporter. 

•  Fielded  and  supported  as  functional  capa¬ 
bilities  in  the  form  of  testable  elements  (the 
first  of  which  is  the  core  element). 

•  Operationally  tested  in  the  core  configuration 
and  later  in  incremental  upgrade  configura¬ 
tions  as  they  are  made  ready  for  introduction. 

•  Sustained  in  its  operational  environment  by 
the  supporters. 

The  EA  Model 

Figure  1  represents  graphically  an  EA  model  and 
its  application  over  time.  The  model  emphasizes 
the  incremental  nature  of  the  EA  approach  and 
the  essential  continual  user  involvement  in  every 
phase  of  development. 

•  The  Service  Chief  or  his  representative  begins 
the  process  when  he  defines  the  overall 
system  operational  concept  and  requirements 
in  functional  terms  based  upon  user  input. 
At  about  the  same  time,  he  also  defines  in 
considerable  detail  the  operational  concept 
and  functional  requirements  for  the  first  sys¬ 
tem  operational  element  to  be  fielded  (the  core 
element).  When  fielded,  the  core  element 
must  provide  a  significant,  identifiable  opera¬ 
tional  capability  and  be  supportable  in  its  in¬ 
tended  operational  environment. 

•  After  the  Service  Chief  or  his  representative 
formulates  an  overal  system  concept  and 
identifies  the  overall  capability  required  in  the 
final  configuration,  the  developer  recom¬ 
mends  for  service  approval  a  systems  archi¬ 
tecture  capable  of  accommodating  system 
evolution  with  minimum  system  redesign.  The 
supporter  identifies  those  minimum  elements 
required  to  sustain  the  system  in  its  in¬ 
tended  operational  environment.  The  archi¬ 
tecture  is  a  critical  element  that  should  be 
structured  with  care  and  some  detail, 
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although  a  high  degree  of  specificity  as  to 
details  may  be  impossible  at  first. 

•  The  evolutionary  development  plan  is  a  serv¬ 
ice  approved  and  funded  product.  Its  goal  is 
achievement  of  the  overall  capability  through 
incremental  development  fielding  and  sup¬ 
porting  of  incremental  upgrades  to  the 
“core,”  or  baseline,  operational  capability. 

•  The  Service  Chief  or  his  representative,  with 
continuing  developer,  supporter,  and  user  in¬ 
put,  defines  the  initial  (Core)  capability  to  be 
developed,  tested  and  fielded.  Significantly, 
the  Core  element  is  not  fielded  until  opera¬ 
tionally  tested  to  determine  its  effectiveness, 
suitability,  and  sustainability.  The  fielded 
incremental  capability  is  then  operated  and 
exercised  by  the  user  and  sustained  by  the 
supporter  in  its  operational  environment,  and 
the  user  provides  recommendations  to  be  ad¬ 
dressed  in  definition  of  later  incremental 
upgrades. 

•  On  a  (most-likely  overlapping)  sequential 
basis,  the  additional  increments  of  capability 
are  defined,  service  approved,  developed, 
operationally  evaluated,  fielded,  and  sup¬ 
ported  in  the  same  way  as  the  initial  incre¬ 
ment. 

As  highlighted  in  Figure  1 ,  funding  for  the  system 
elements  is  also  incremental  in  nature.  Budget  ap¬ 
proval  and  funding  for  each  element  is  made 
available  only  after  the  operational,  performance 
characteristics  and  support  requirements  of  that 
element  have  been  defined  in  sufficient  detail  for 
development  of  that  element  to  begin. 

In  the  interest  of  simplicity,  the  model  does  not  pre¬ 
sent  the  contribution  that  an  Off-Line  Develop¬ 
ment,  Test  and  Support  Facility  may  make  to  the 
development  process.  Such  a  facility,  utilizing 
operational  mock-ups,  simulations  and  a  software 
laboratory  will  generally  be  required  for  system 
development,  for  development  testing,  and  for 
system  integration.  The  facility  will  also  serve  to 
help  integrate  the  user  and  tester  input  with  the 
development  activities,  and  will  provide  the 


capability  to  develop  and  evaluate  hardware  and 
software  updates. 

Real-life  applications  of  the  EA  strategy  have  been 
limited.  One  of  the  few  programs  currently  using 
the  EA  approach  is  the  WIS-World-Wide  Military 
Command  and  Control  System  (WWMCCS)  Infor¬ 
mation  System.  The  WIS  is  a  large,  software  domi¬ 
nant  C2  system  with  many  of  the  characteristics 
that  suggest  use  of  an  EA  strategy.  The  WIS  ap¬ 
plication  of  EA,  as  shown  in  Figure  2,  can  be  seen 
to  track  fairly  closely  with  the  more  generalized 
EA  model  (Figure  1). 

What  EA  Is  Not 

While  evolutionary  acquisition  experience  is 
limited,  the  approach  is  not  totally  unknown.  In 
fact,  in  addition  to  its  proponents,  EA  has  already 
gained  a  few  skeptics.  Because  the  concept  is  not 
universally  understood,  it  is  well  to  underscore 
several  things  that  EA  clearly  is  not.  The  EA  is  not. 

•  An  approach  that  provides  for  unconstrained 
requirements  growth  and  an  unbridled 
budget. 

•  A  single  strategy  ready  for  application  to  all 
C2  system  acquisition  efforts. 

•  A  checklist  approach  that  will  greatly  simplify 
C2  acquisition. 

•  A  strategy  that  is  identical  to  those  recom¬ 
mended  in  the  studies  referenced  on  page  3 
of  this  guide. 

•  A  free  ticket  to  exemption  from  competition, 
disciplined  configuration  management, 
testing  or  ILS  planning.  (The  EA  poses 
additional  challenges  in  these  areas  and 
requires  careful  tradeoff  analysis  to  reach 
smart  decisions  that  will  benefit  the  total 
acquisition.) 

It  is  important  to  recognize  that  once  the  decision 
is  made  to  pursue  an  evolutionary  acquisition 
strategy  with  incremental  “deliverables,”  the  deci¬ 
sion  itself  is  not  incremental — for  all  practical  pur¬ 
poses,  it  locks  in  a  number  of  subsequent  actions 
to  an  identified  line  of  approach. 
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SECTION  5 


AREAS  REQUIRING  SPECIAL  CONSIDERATION 
WHEN  USING  EVOLUTIONARY  ACQUISITION 


While  evolutionary  acquisition  could  be  the  best 
alternative  approach  to  use  in  acquiring  certain 
software  dominant  C2  systems,  EA  of  course  is  no 
panacea.  To  successfully  formulate  and  execute 
an  EA  strategy,  a  number  of  areas  must  be  given 
special  consideration.  Key  areas  requiring  such 
consideration  are  discussed  below. 

The  Acquisition  Executive,  the  User,  the  Sur¬ 
rogate  User,  the  Supporter,  the  independent 
Tester  and  the  Developer 

In  conventional  acquisition  programs,  relation¬ 
ships  among  these  six  entities  sometimes  may  be 
rather  formal,  and  negotiations  among  them  may 
be  conducted  at  arm’s  length.  For  EA  to  be  suc¬ 
cessful,  some  of  the  roles  of  these  entities  may 
need  to  be  redefined,  and  most  of  the  relationships 
need  to  be  closer  and  more  cooperative  than  has 
been  the  norm.  Five  areas  in  which  relations  need 
to  be  carefully  considered  are  as  follows: 

•  System  Operational  Capabilities 

In  system  acquisition,  a  surrogate  user  fre¬ 
quently  has  the  primary  role  in  specifying  the 
desired  operational  requirements  for  the 
system,  while  the  real  user  may  be  rather  far 
removed  from  this  process,  depending  upon 
service  procedures.  In  using  EA  to  acquire 
C2  systems,  a  major  premise  is  that  the  real 
user— working  in  a  close,  continual  relation¬ 
ship  with  the  developer  and  supporter- 
should  have  a  major  voice  in  formulating 
operational  requirements  and  in  defining  de¬ 
tailed  system  characteristics  once  operational 
requirements  have  been  defined.  Thus  the 
traditional  roles  of  the  user  and  of  the  sur¬ 
rogate  user  may  have  to  be  redefined  for  a 
particular  program,  in  accord  with  the  needs 
of  that  program.  The  complexity  of  these  rela¬ 
tionships  is  likely  to  be  even  greater  in  cases 
where  the  real  user  is  in  a  service  different 
from  that  of  the  developer.  A  Memorandum 
of  Understanding  or  Agreement  is  recom¬ 
mended  in  these  instances. 

•  Operational  Test  and  Evaluation 

Each  service  has  within  its  organization  an  in¬ 


dependent  tester  who  is  responsible  for  all 
Operational  Test  and  Evaluation.  A  premise 
involved  in  using  EA  to  acquire  C2  systems 
is  that  C2  systems  are  tested,  incrementally 
beginning  with  the  core  system,  to  determine 
whether  the  core  system  (or  the  core  system 
plus  incremental  upgrades  to  that  system) 
meets  the  operational  requirement.  The  user, 
in  operating  the  system,  is  a  critical  part  of 
the  system  while  he  is  using  it  in  his  opera¬ 
tional  environment.  The  independent  tester 
evaluates  the  operational  effectiveness  and 
operational  suitability  of  the  system  in  the 
upgrade  status  in  which  it  is  presented,  and 
is  likely  to  employ  user  forces  to  do  so. 
Therefore,  the  user  gains  more  extensive 
experience  and  makes  recommendations  for 
establishment  of  operational  requirements  for 
subsequent  system  increments.  This  process 
of  evolution  of  requirements  and  the  introduc¬ 
tion  of  upgrades,  distinguishes  the  evolu¬ 
tionary  approach  from  the  more  classical 
weapon  acquisition  process.  The  independent 
tester  is  an  important  player  in  this  process. 
It  is  imperative  that  he  become  involved  early 
in  the  program  development  phase  and  main¬ 
tain  a  direct  and  continuous  liaison  with  the 
developer  and  user  throughout  the  EA  proc¬ 
ess,  so  that  operational  test  and  evaluation 
can  proceed  with  maximum  rapidity. 

•  Test  and  Evaluation  Planning 

Both  the  software-intensive  nature  of  the 
systems  and  the  evolutionary  approach  may 
affect  conventional  test  planning  and  evalua¬ 
tion.  In  particular,  there  is  likely  to  be 
greater  concentration  on  contractor  testing 
than  government-conducted  development 
testing.  This  should  be  addressed  in  the 
TEMP  from  the  outset,  with  an  objective  of 
exploiting  integrated  testing  without  losing 
critical  independence  of  contractor/develop¬ 
er/user  views. 

•  Developer-User-Supporter  Interaction 

In  some  conventional  acquisition  programs, 
the  developer  and  the  real  user  may  have 


little  interaction  with  each  other  during  the 
course  of  the  development.  For  successful 
use  of  EA  to  acquire  C2  systems,  the  devel¬ 
oper,  user,  and  the  supporter  need  to  work 
more  closely  together,  over  a  lengthy  period 
of  time. 

•  Program  Review  and  Approval 

In  conventional  acquisition,  there  are  nor¬ 
mally  only  a  few  times  that  the  program 
manager  needs  to  obtain  approval  of  the 
acquisition  executive  to  allow  him  to  proceed 
with  his  program.  Such  approval  is  normally 
required  at  each  of  the  major  program  mile¬ 
stones.  Associated  with  each  such  milestone 
(on  a  major  program)  the  program  manager 
may  have  to  give  50-75  briefings  over  a 
period  of  a  number  of  months.  For  an  EA  pro¬ 
gram,  each  increment  of  capability  might 
require  approval  of  the  acquisition  executive 
and,  perhaps,  at  each  of  several  stages 
of  development.  Under  these  circumstances, 
it  would  be  necessary  to  greatly  streamline 
the  review  and  approval  process.  For  ex¬ 
ample,  in  some  instances  involving  a  simple 
program  where  the  final  configuration  can 
be  defined  in  some  detail,  the  total  system 
might  be  validated  as  a  single  requirement 
and  each  increment  treated  as  a  “Release” 
so  long  as  the  program  remains  within  des¬ 
ignated  performance  and  dollar  thresholds. 

Program  Management 

Frequently  for  conventional  programs,  a  program 
office  is  not  established  until  Milestone  1  or  later. 
Often  the  program  office  is  not  well  staffed  with 
experienced  people  during  the  early  phases  of  a 
program  compared  with  later  program  phases. 

In  using  EA,  it  is  important  that  a  capable  program 
office  be  established  very  early  in  the  program 
because:  1)  the  acquisition  strategy  must  be  de¬ 
fined  early,  2)  roles  and  relationships  of  the  various 
key  players  in  the  acquisition  process  (as  dis¬ 
cussed  above)  need  to  be  negotiated  early,  and 
3)  the  program  sponsor  will  need  program  office 
support  in  defining  the  fundamental  architecture 
and  support  structure  underlying  the  entire 
system. 

Another  consideration  involving  the  program  of¬ 
fice  is  that  the  office  must  generally  be  staffed 
more  heavily  to  allow  it  to  manage  all  phases  of 
the  acquisition  cycle  concurrently;  because,  with 
the  use  of  EA  several  increments  may  be  under 
development  at  any  one  time,  and  these  various 


increments  may  be  at  different  stages  of  the  ac¬ 
quisition  cycle. 

Competition  in  Contracting 

Four  closely  related  areas  of  work  involved  in 
evolutionary  acquisition  require  special  considera¬ 
tion  relative  to  competition  in  contracting.  These 
areas  are:  1)  system  architecture;  2)  development 
and  maintenance  of  the  Off-Line  Development, 
Test  and  Support  Facility;  3)  system  configuration 
management,  and  4)  logistics  support.  These 
areas  of  work  may  continue  not  only  throughout 
the  evolutionary  acquisition  period,  but  most  likely 
throughout  the  lifetime  of  the  C2  system,  since  it 
is  likely  that  the  system  will  continue  to  evolve  to 
some  extent  throughout  its  lifetime. 

It  is  important  that  continuity  be  maintained  in  each 
of  the  above  four  functional  areas  throughout  the 
acquisition  process  and  continue  for  the  opera¬ 
tional  lifetime  of  the  system.  Thus,  these  functions 
must  be  provided  directly  by  the  government;  or, 
alternatively,  the  particular  contractor(s)  perform¬ 
ing  the  functions  must  be  retained  for  a  number 
of  years.  Changing  contractors  in  these  areas  at 
infrequent  intervals  might  take  place  without  un¬ 
due  impact  on  the  program.  However,  frequent 
changes  in  these  areas  would  be  highly  disruptive 
to  the  program,  and  it  may  be  preferable  that  the 
government  gear-up  to  perform  the  function  “in- 
house.” 

On  the  other  hand,  normal  practices  concerning 
competition  most  likely  could  be  employed  for  the 
tasks  of  developing  each  of  the  increments  of  the 
system’s  operational  capability.  Here,  the  ineffi¬ 
ciencies  of  new  contractors  learning  the  system 
may  or  may  not  offset  the  positive  values  of 
competition. 

In  keeping  with  the  evolutionary  acquisition  ap¬ 
proach,  special  emphasis  should  be  placed  on 
early  development  of  an  Acquisition  Plan  to  en¬ 
sure  that  procurement  leadtime  constraints  are 
noted  and  addressed  up  front.  The  EA  “fast 
march”  will  necessitate  innovative  contracting  ap¬ 
proaches,  and  early  planning  would  afford  max¬ 
imum  opportunity  to  utilize  effective  competition 
practices.  For  example,  a  two-phase  process 
might  be  used: 

•  The  first  phase  would  involve  multiple 
awards  with  the  resulting  contracts  address¬ 
ing  the  core  capability  of  the  system.  Poten¬ 
tial  teaming  arrangements  would  be  in¬ 
dicated.  Conceptual  segments  and  ap- 


proaches  to  incremental  upgrades  would  be 
discussed,  and  a  system  specification 
prepared.  Demonstration  models  would  be 
deliverables,  where  feasible. 

•  The  second  phase  would  involve  selection 
of  a  contractor  for  a  systems  engineering 
integration  contract.  This  would  still  permit 
competition  at  the  second  tier  for  individual 
increments. 

This  approach  would  tend  to  be  time-intensive  up 
front,  but  would  pay  off  with  a  smoother  transition 
in  the  second  phase,  and  would  provide  much 
greater  accountability  and  confidence  in  the  ade¬ 
quacy  of  the  final  system  capability. 

Control  and  Stabi  ity  of  the  Development 
Process 

Although  evolutionary  acquisition  is  by  definition 
evolutionary,  it  is  important  that  it  be  partitioned 
into  fairly  distinct  increments,  and  that  once  the 
development  of  a  particular  increment  is  well 
underway,  changes  in  functional  requirements 
pertaining  to  that  increment  be  made  only  if  the 
changes  are  very  important.  These  points  require 
strong  emphasis  because  of  a  combination  of 
several  circumstances: 

•  AC2  system  is  mostly  made  of  software. 

•  The  user,  in  the  case  of  an  EA  program, 
most  likely  would  continually  be  able  to  iden¬ 
tify  changes  he  would  like  to  see  made. 

•  Many  people  (including  undoubtedly  some 
users  and  some  program  management  per¬ 
sonnel)  unfortunately  and  erroneously  believe 
software  changes  are  easy  to  make  at  any 
time,  because  "it's  simply  a  matter  of  pro¬ 
gramming." 

•  In  view  of  these  last  two  circumstances,  it 
might  seem  natural  for  the  program  manage¬ 
ment  office  frequently  to  want  to  explore  with 
the  development  contractor  the  idea  of 
making  various  “minor"  software  changes. 

•  Computer  programmers  are  commonly  very 
optimistic  in  assessing  the  impact  of  making 
"minor”  software  changes,  particularly  if  the 
program  management  office  seems  inter¬ 
ested  in  making  the  changes. 

•  In  reality,  such  software  changes  made 
downstream  in  the  development  phase  (of  a 
given  increment)  are  very  expensive  to 
make,  and  may  lead  to  software  “bugs"  that 
might  be  very  difficult  to  detect  and  correct. 


As  a  rule  of  thumb,  adding  a  small  addi¬ 
tional  capability  to  the  system  by  a  software 
change  downstream  in  the  development 
cycle  is  about  ten  times  as  expensive  as 
it  would  be  to  achieve  the  same  result  by 
incorporating  the  capability  into  the  system 
beginning  at  the  start  of  a  particular  incre¬ 
ment.  Experience  has  shown  that  lack  of 
tight  configuration  control  of  software  leads 
to  difficulty  in  operational  testing  and  later 
during  in-service  use,  with  greatly  in¬ 
creased  cost  often  resulting  as  well  as  a 
delay  in  user  satisfaction. 

•  Any  changes  to  the  configuration  need  to 
be  assessed  from  a  supportability  aspect. 

Configuration  Management,  and  Documenta¬ 
tion  of  System  Design 

For  any  acquisition  program,  configuration 
management  and  full  documentation  of  the  design 
of  the  system  are  important,  and  the  technical  data 
package  is  the  key  to  disciplined  documentation. 
For  an  evolutionary  acquisition  program— possibly 
involving  both  an  evolving  architecture  and  a 
series  of  system  increments— it  is  especially  im¬ 
portant  that  configuration  management  and 
system  documentation  be  comprehensive  and  of 
high  quality. 

Production  and  Installation 

In  considering  evolutionary  acquisition  of  C2 
systems,  attention  is  normally  focused  primarily 
upon  architecture,  requirements,  development,  in¬ 
tegration  and  evaluation;  with  relatively  little  atten¬ 
tion  given  to  production  and  installation  of  the 
systems. 

Relative  to  hardware,  most  of  the  issues  concern¬ 
ing  production  and  supportability  of  the  hardware 
of  C2  systems  are  not  greatly  different  from  the 
issues  concerning  production  of  the  hardware  of 
many  other  types  of  systems.  One  notable  dif¬ 
ference  in  hardware  installation,  however,  is 
seated  in  the  fact  that  many  large  C2  systems  are 
few  in  number  or  even  "one-of-a-kind." 

Concerning  software,  once  the  development  is 
complete,  production  and  distribution  consists 
primarily  of  copying  digital  data  from  one  storage 
medium  to  another.  Thus,  the  cost  of  producing 
and  distributing  software  is  significantly  less  than 
its  development. 

Installation  of  software  (exclusive  of  software  in¬ 
tegration  and  test)  is  also  generally  a  trivial  proc¬ 
ess,  involving  primarily  simply  reading  digital  data 


from  a  magnetic  tape  or  disk  into  a  computer’s  in¬ 
ternal  memory.  Installation  includes  testing  to  en¬ 
sure  it  was  installed  correctly. 

Thus,  since  most  of  the  costs  of  C2  systems 
typically  are  in  software,  and  since  the  costs  of  pro¬ 
duction  of  software  are  negligible,  it  is  appropriate 
that  most  of  the  attention  in  the  acquisition  of  C2 
systems  be  given  to  requirements,  architecture, 
development,  evaluation,  integration  and  support 
and  the  resultant  life-cycle  cost  of  support. 


Because  software  maintenance  activities  result  in 
functional  performance  changes  to  the  software, 
adequate  configuration  management  procedures 
must  be  observed  in  the  maintenance  process, 
and  systems  documentation  (technical  data 
package)  must  be  updated  to  reflect  the  program 
changes.  This  practice  must  be  followed  for  each 
software  increment  or  phase  that  is  released  for 
use. 

For  C2  systems  acquired  by  means  of  evolu- 


Software  Maintenance  and  Control 

Maintenance  of  hardware  consists  largely  of  ac¬ 
tions  to  determine  whether  the  hardware  is  func¬ 
tioning  properly,  actions  to  prevent  wear-out  of 
components,  actions  to  correct  for  drift  in  the  func¬ 
tional  characteristics  of  components,  and  actions 
to  repair  or  replace  badly  worn  or  failed  com¬ 
ponents.  While  the  extent  of  the  need  for 
maintenance  and  the  ease  with  which 
maintenance  can  be  performed  are  determined  to 
a  large  extent  by  the  design  and  manufacture  of 
the  hardware,  maintenance  itself  is  concerned 
primarily  with  the  adjustment,  repair  and  replace¬ 
ment  of  parts  of  the  system  which  drift,  wear  out, 
burn  out  or  break. 

Even  though  the  term  “maintenance”  is  general¬ 
ly  used  in  both  cases,  maintenance  of  hardware 
and  maintenance  of  software  are  two  radically  dif¬ 
ferent  things.  Software  does  not  drift,  wear  out, 
burn  out  or  break,  and  thus  requires  no 
maintenance  of  the  kind  required  for  hardware. 
But,  software  does  malfunction  when  combina¬ 
tions  of  options  are  used  that  were  never  tested. 
Testing  does  not  find  all  the  bugs.  These  opera¬ 
tional  malfunctions  do  require  software 
maintenance  and  support. 

Software  maintenance,  rather  than  involving 
maintenance  in  the  hardware  sense,  is  concerned 
with  two  quite  different  activities.  These  two  ac¬ 
tivities  are: 


•  Detecting,  localizing  and  analyzing  software 
bugs  (design  deficiencies  remaining  in  the 
software);  and  then  either  correcting  the 


bugs— by  changing  the  design  of  the 
software— or  devising  means  to  allow  the 
system  to  operate  adequately  in  spite  of  the 
bugs. 

Changing  the  existing  functional  character¬ 
istics  of  the  system  by  modifying  the  design 
o*  the  software,  and  adding  additional  func¬ 
tional  capability  to  the  system  by  designing 
and  adding  additional  software. 


tionary  acquisition,  it  seems  almost  axiomatic  that 
the  above  software  functions  must  be  performed 
by  the  development  community,  rather  than  by  the 
support  community,  during  the  full  period  of  the 
acquisition.  Indeed,  this  is  mandatory  if  difficulty 
in  operational  test  and  evaluation  is  to  be  avoided. 
Moreover,  even  after  completion  of  the  basic  ac¬ 
quisition  cycle,  C2  systems  are  likely  to  undergo 
subsequent  incremental  changes  to  meet  chang¬ 
ing  operational  conditions  and  to  incorporate 
significant  new  capabilities.  Thus,  it  is  likely  that 
a  software  development  capability  and  the  Off-Line 
Development,  Test  and  Support  Facility  would  be 
maintained  for  the  operational  life  of  the  C2 
system. 

In  view  of  the  circumstances,  the  transition  of  soft¬ 
ware  design,  control,  production  and  maintenance 
from  the  development  community  to  the  support 
community  should  be  treated  on  a  case-by-case 
basis  for  each  major  C2  system.  However,  from 
the  very  beginning,  the  developer  must  consider 
support  alternatives  in  the  operational  environment 
and  either  modify  designs  to  increase  supportabili- 
ty  or  plan  for  the  necessary  support  to  be  available. 
Early  in  the  conceptual  stage,  these  tradeoffs 
should  be  assessed— to  include  consideration  of 
diagnostics/prognostics,  design  for  discard— while 
they  are  still  feasible  to  achieve. 

User  Designed/Maintained  Software 

With  the  advent  of  low-cost  computers,  low-cost 
and  easy-to-use  high-level  software  (such  as  data¬ 
base  management  systems)  and  expanding  soft¬ 
ware  literacy,  it  is  to  be  expected  that  some  users 
will  wish  to  design  and  maintain  their  own  in¬ 
dividual  “micro”  C2  systems,  including  design¬ 
ing/maintaining  their  own  software.  Such  software 
might  be  designed  to  run  on  separate  micro  (or 
mini)  computers,  or  on  large  machines  available 
to  the  users. 

While  a  do-it-yourself  micro  system  might 
sometime  be  desirable,  such  a  system  can  also 
be  a  source  of  difficulties. 


Difficulties  might  arise  due  to:  1)  possible  lack  of 
integration  of  such  a  system  within  a  larger  C2 
framework,  2)  possible  lack  of  adequate  system 
documentaion,  and  3)  possible  lack  of  adequate 
configuration  management. 

The  better  the  acquisition  community  can  meet  the 
user’s  needs  in  a  timely  and  adequate  way,  the 
less  likely  the  users  will  be  to  act  as  their  own 
system  developers. 

Product  Assurance 

Solid  product  assurance  planning  must  link  all 
aspects/phases  of  the  system  and  be  visible  at 
decision  milestones.  Such  planning  should 


highlight  the  fact  that,  in  an  evolutionary  approach, 
the  developer’s  responsibility  must  extend  through 
user/fielded  verification,  and  may  entail  special 
maintenance  or  warranty  provisions. 

Integrated  Logistic  Support 

As  with  conventional  acquisition  approaches,  ILS 
is  critical  in  evolutionary  acquisition  to  assure  that 
design  is  influenced  by  support  requirements  and 
that  support  is  available  for  operational  sustain¬ 
ment.  In  the  C2  environment,  supportability  of  the 
software  and  the  equipment  which  operates  the 
software  is  critical  to  the  supportability  of  the 
overall  weapon  system. 


SECTION  6 


OMB  AND  OSD  POLICY  GUIDELINES 


Background 

Evolutionary  Acquisition  is  an  alternative  to  the  ac¬ 
quisition  process  normally  used  to  acquire 
selected  command  and  control  systems.  Its 
genesis  is  found  within  the  principles  of  flexibility 
and  innovativeness  stated  and  implied  by  policies 
promulgated  by  the  Office  of  Management  and 
Budget  as  well  as  OSD. 

OMB  Circular  A-109  identifies  seven  “Major 
System  Acquisition  Management  Objectives.” 
One  of  these  states: 

Tailor  an  acquisition  strategy  for  each  pro¬ 
gram,  as  soon  as  the  agency  decides  to  solicit 
alternative  system  design  concepts,  that 
could  lead  to  the  acquisition  of  a  new  major 
system  and  refine  the  strategy  as  the  pro¬ 
gram  proceeds  through  the  acquisition 
process... 

This  objective,  which  emphasizes  a  unique 
strategy  for  each  program,  implies  a  requirement 
for  flexibility  that  DOD  supported  in  its  5000  series 
of  directives  and  instructions.  Among  the  1 2  “pro¬ 
cedures”  contained  in  DODD  5000.1,  Major 
Systems  Acquisitions,  March  12,  1986,  is  the 
following: 

9.  Tailoring  and  Flexibility.  The  acquisition 
strategy  developed  for  each  major  system  ac¬ 
quisition  shall  consider  the  unique  cir¬ 
cumstances  of  individual  programs.  Pro¬ 
grams  shall  be  executed  with  innovation  and 
common  sense.  To  this  end,  the  flexibility  in¬ 
herent  in  this  Directive  shall  be  used  to  tailor 
an  acquisition  strategy  to  accommodate  the 
unique  aspects  of  a  particular  program  as 
long  as  the  strategy  remains  consistent  with 
the  basic  logic  for  system  acquisition 
problem-solving  and  the  principles  in  this 
Directive  for  business  and  management 
considerations... 

Applicability  to  C2 

DODI  5000.2,  Major  System  Acquisition  Pro¬ 
cedures,  March  12,  1986,  identifies  39  “Acquisi¬ 
tion  Management  and  System  Design  Principles” 
and  states  that,  “The  following  principles  shall  be 


considered  in  planning  major  system  acquisi¬ 
tions.”  Among  these  principles,  the  following  is 
included: 

Evolutionary  Development  and  Acquisi¬ 
tion  of  Command  and  Control 
Systems.1 

The  footnote  identified  by  1  references  Defense 
Acquisition  Circular  76-43,  “Acquisition  Manage¬ 
ment  and  System  Design  Principles,”  February 
28,  1983,  which  provides  a  discussion  of  Evolu¬ 
tionary  Acquisition  and  other  acquisition  manage¬ 
ment  principles.  The  circular  was  published  as  in¬ 
formation  guidance,  not  a  substitute  for  regula¬ 
tions,  directives  or  instructions.  The  discussion  of 
Acquisition  Strategy  is  reproduced  below  and 
reflects  the  DOD  support  of  the  principles  of  flex¬ 
ibility,  innovativeness  and  uniqueness  in  the 
development  of  each  program’s  acquisition 
strategy: 

6.  Acquisition  Strategy 

a.  An  initial  program  acquisition  strategy 
will  be  developed  by  the  DOD  Component 
concerned  for  each  major  system  acquisi¬ 
tion  when  a  new  start  is  proposed.  The  ac¬ 
quisition  strategy  should  be  tailored  to  the 
unique  circumstances  of  the  program.  Pro¬ 
posed  exceptions  to  applicable  DOD  Direc¬ 
tive  and  Instructions  will  be  identified  in  the 
acquisition  strategy  as  it  evolves.  Advice 
and  assistance  should  be  sought  from 
business  and  technical  advisors  and  ex¬ 
perienced  managers  of  other  major  system 
programs. 

b.  The  acquisition  strategy  is  the  con¬ 
ceptual  basis  of  the  overall  plan  that  a  pro¬ 
gram  manager  follows  in  program  execu¬ 
tion.  it  reflects  the  management  concepts 
that  will  be  used  in  directing  and  control¬ 
ling  all  elements  of  the  acquisition  to 
achieve  specific  goals  and  objectives  of  the 
program  and  to  ensure  that  the  new 
system  satisfies  the  approved  mission 
need.  The  acquisition  strategy  encom¬ 
passes  the  entire  acquisition  process  of  the 


basic  system,  preplanned  product  im¬ 
provements  (P3I),  and  post-production 
support.  The  strategy  must  be  developed 
in  sufficient  detail,  at  the  time  of  issuing 
solicitations  for  the  concept  exploration 
phase,  to  permit  competitive  exploration  of 
alternative  system  design  concepts.  Suf¬ 
ficient  planning  must  be  accomplished  for 
succeeding  program  phases,  that  involve 
design,  competition,  provisioning  and  sup¬ 
port  economies,  and  production  source 
availability. 

c.  The  acquisition  strategy  must  evolve 
through  an  iterative  process  and  become 
increasingly  definitive  in  describing  the  in¬ 
terrelationship  of  the  management, 
technical,  business,  resource,  force  struc¬ 
ture,  support  testing,  equipment  standar¬ 
dization,  and  other  aspects  of  the  program. 
Normally,  the  baselining  and  definition  of 
a  program  will  progress  from  establish¬ 
ment  of  oprational  requirements  (JMSNS) 
to  functional  characteristics  (Milestone  I) 
to  an  allocated  functional  baseline 
(Milestone  II)  to  a  production  baseline 
(Milestone  III). 

d.  Acquisition  programs  will  be  executed 
with  innovation  and  common  sense.  The 
flexibility  inherent  in  DODD  5000.1  and 
DODI  5000.2  will  be  used  to  tailor  an  ac¬ 
quisition  strategy  to  accommodate  the 
unique  aspects  of  a  particular  program,  as 
long  as  the  strategy  remains  consistent 
with  the  basic  logic  for  system  acquisition 
problem  solving  and  good  business  and 
management  principles. 

The  Circular  also  provides  a  brief  description  of 
the  characteristics  of  C2  systems  that  may  require 
an  EA  approach  and  discusses  that  approach  in 
general  terms: 

27.  Command  and  Control  C2  Systems. 

a.  The  types  of  systems  that  augment  the 
decision-making  and  decision  executing 
functions  of  operational  commanders  and 
their  staffs  in  the  performance  of  C2  require 
a  tailored  acquisition  strategy.  The  principal 
characteristics  of  such  systems  are:  (1)  ac¬ 
quisition  cost  normally  is  software  dominated; 
(2)  the  system  is  highly  interactive  with  the 
actual  mission  users  and  is  highly  dependent 
on  the  specific  doctrine,  procedures,  threat, 
geographic  constraints,  and  mission 


scenarios  of  these  users;  and  (3)  these 
systems  are  characterized  by  complex  and 
frequently  changing  internal  and  external  in¬ 
terfaces  at  multiple  organizational  levels, 
some  of  which  may  be  inter-Service  and 
multinational. 

b.  The  use  of  pre-planned  product  improve¬ 
ment  (P3I)  is  a  procedure  highly  appropriate 
to  such  systems  and  should  be  considered 
when  appropriate.  C2  systems  generally  re¬ 
quire  an  evolutionary  acquisition  approach. 
This  is  an  adaptive,  incremental  approach 
where  a  relatively  quickly  fieldable  “core”  (an 
essential  increment  in  operational  capabili¬ 
ty)  is  acquired  initially.  This  approach  also  in¬ 
cludes  with  the  definition  of  the  “core 
capability”;  (1)  a  description  of  the  overall 
capability  desired;  (2)  an  architectural 
framework  where  evolution  can  occur  with 
minimum  subsequent  redesign;  and  (3)  a 
plan  for  evolution  that  leads  towards  the 
desired  capability. 

c.  Programming,  budget  approval,  and  ac¬ 
quisition  management  must  be  tailored  to  en¬ 
courage  and  enable  early  implementation 
and  field  evaluation  of  a  “core”  system. 
Subsequent  increments  must  be  based  on 
continuing  feedback  from  operational  use, 
testing  in  the  operational  environment, 
evaluation  and  (in  some  cases)  application 
of  new  technology.  Operational  and  interface 
requirements  and  operational  utility  criteria 
should  be  evolved  with  the  participation  of  ac¬ 
tual  mission  users  (or  lead  user  and  ap¬ 
propriate  surrogate  for  multi-user  systems). 
There  must  be  regular  and  continual  interac¬ 
tion  with  developers,  independent  testers, 
and  logisticians. 

d.  The  user  will  support  the  independent 
T&E  agency  in  determining  readiness  for 
operational  use  of  the  “core”  system  and 
work  closely  with  the  development  activity 
and  independent  tester  in  evaluating  subse¬ 
quent  increments  of  new  technology.  A  cen¬ 
tralized  facility  will  be  used  to  accomplish 
post  deployment  software  support  of  fielded 
increments  under  centralized  configuration 
management.  Consideration  must  be  given 
to  the  use  of  existing  commercial  equipment, 
related  system  software  and  firmware,  and 
contractor  maintenance  (with  warranties) 
whenever  logistic,  interoperability,  readiness 
considerations,  and  field  conditions  permit  it. 
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e.  Those  elements  of  C2  systems  that  must 
survive  and  endure  in  strategic  or  theater 
nuclear  warfare  will  be  at  least  as  survivable 
as  the  weapon  system  they  directly  or  in¬ 
directly  support.  A  proper  mix  of  survivabili¬ 
ty  techniques  must  be  applied.  Existing 
military  and  commercial  hardware,  software, 
and  procedures  should  be  used  only  if  it  can 
be  demonstrated  that  they  can  be  protected 
against  and  made  resistance  to  wide-area 
threats  such  as  jamming,  spoofing  and  elec¬ 


tromagnetic  pulse,  and  that  they  can  provide 
reasonable  functional/system/path  redundan¬ 
cy  against  direct  attack  and  sabotage.  In¬ 
teroperability  and  battlefield  sustainability  will 
be  key  considerations. 

f.  The  procedures  described  above  are 
equally  applicable  to  similar  non-major  C2 
systems  as  well  as  counter-C3,  elec¬ 
tromagnetic  countermeasures,  and  electronic 
warfare  systems. 
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SECTION  7 
SUMMARY 


Evolutionary  Acquisition  is  an  alternative  approach 
to  acquisition  of  Command  and  Control  Systems. 
The  OSD  policy  makes  available  the  use  of  EA  for 
such  systems  whose  capabilities  are  to  be  in¬ 
troduced  incrementally,  and  the  Joint  Logistics 
Commanders  endorse  this  OSD  guidance. 

Considered  most  broadly,  EA  consists  of  first 
defining  the  requirement  and  the  general  outline 
of  the  system;  and  then  sequentially  defining,  fun¬ 
ding,  developing,  testing,  fielding,  supporting,  and 
evaluating  increments  of  the  system  beginning 
with  a  core  or  baseline  system,  to  be  enhanced 
through  incremental  upgrades. 


Successful  use  of  EA  requires  a  number  of 
modifications  to  the  normal  practices  of  systems 
acquisition.  Of  particular  importance  are  the  rela¬ 
tionships  among  the  acquisition  executive,  the 
user,  the  surrogate  user,  the  independent  tester, 
the  supporter  and  the  developer;  all  of  which  must 
be  of  high  quality  for  EA  developments  to  be  per¬ 
formed  successfully.  The  Joint  Logistics  Com¬ 
manders  will,  as  necessary,  assist  subordinate 
commanders  and  their  program  managers  in 
negotiating  any  special  arrangements  which  might 
be  required  to  successfully  implement  evolutionary 
acquisition. 
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